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ABSTRACT:  Currently  Modeling  and  Simulation  (M&S)  requirements  in  support  of  Command, 

Control,  Communications,  Computer,  Intelligence,  Surveillance  and  Reconnaissance  (C4ISR)  systems 
tend  to  be  developed  following  the  effected  C4ISR  system  fielding.  The  resultant,  delayed,  fielding  of 
the  supporting  M&S  not  only  causes  several  problems  from  the  viewpoint  of  the  user  (i.e.  lack  of 
training)  but  also  is  a  potential  advantage  lost  to  both  the  C4ISR  and  M&S  system  developers.  The 
popularity  of  the  spiral  development  process  with  its  shortened  requirement  to  fielding  timelines 
compounds  this  problem. 

M&S  development  conducted  for  a  recent  Joint  Expeditionary  Force  Experiment  (JEFX)  produced  an 
interface  between  the  Air  Warfare  Simulation  (AWSIM)  and  the  Theater  Battle  Management  Core 
System  (TBMCS)  which  modified  the  traditional  spiral  development  process  as  it  occurs  between 
C4ISR  systems  and  supporting  M&S.  This  modified  process  produced  a  workable  interface  faster, 
which  not  only  provided  users  training  prior  to  C4ISR  system  but  also  aided  in  the 
requirements/acquisition  and  test  and  evaluation  processes.  This  paper  discusses  the  modified  spiral 
development  process,  its  effects  on  the  JEFX  process  and  presents  some  lessons  learned  and 
suggestions  for  future  modifications. 
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Modeling  &  Simulation  fM&St 
Chaiienoes 

There  are  several  challenges  facing  the 
modeling  and  simulation  community  today. 
The  reduction  in  cost  coupled  with  the 
increase  in  power  of  readily  available 
processors  has  made  modeling  and 
simulation  technologies  available  to  a  much 
wider  audience.  Along  with  the  wider 
availability  has  come  a  more  selective 
audience,  the  bar  has  been  raised  on  what 
is  acceptable  and  what  will  gather  dust  in 
the  corner.  Users  today  require  a  much 
higher  degree  of  realism  and  they  want  new 
requirements  met  faster.  This  is  especially 
true  in  exercising  battlestaffe  in  the 
employment  of  Command,  Control, 
Comrnunication,  Computer,  Intelligence,’ 
Surveillance  and  Reconnaissance  (C4ISR) 
systems. 

C4ISR  systems  are  being  acquired  and 
modified  at  an  ever  increasing  rate  and  the 
golden  rule  of  “training  the  way  you  fighf 
dictates  that  operators  use  their  go-to-war 
systems  for  training.  This  requires  that 
modeling  and  simulation  systems  integrate 
with  each  of  these  C4ISR  systems.  This 
paper  will  present  a  modification  to  the 
current  spiral  development  process  which 
allows  M&S  systems  to  not  only  be  fielded 
with  the  C4ISR  systems  they  support  but 
benefit  additional  warfighter  areas  as  well. 

Why  Integrate 

Using  your  real-world  system  to  train  on  is 
certainly  a  driving  reason  to  integrate  C4ISR 
systems  with  the  M&S  that  can  stimulate  it, 
but  is  that  the  only  benefit?  If  one  considers 
that  the  synthetic  battlespace  presented  by 
M&S  can  replace  portions,  or  all  of  the  real- 
world  battlespace,  and  if  done  properly,  not 
only  the  operator,  but  the  C4ISR  system 
itself  cannot  tell  the  difference,  then  a  wealth 
of  opportunities  opens  up. 

Very  often  system  deficiencies  do  not 
surface  until  a  system  is  fielded.  Lab 
conditions  do  not  accurately  represent  the 
flood  of  information  which  can  occur  in  a 
contingency  operation.  M&S  provides  the 


capability  to  produce  realistic  (or  excessive  if 
you  prefer)  traffic  amounts  to  discover 
problems  prior  to  fielding  for  purposes  of  test 
and  evaluation  or  experimentation. 
Additionally,  these  test  environments  can 
help  organizations  define  their  future 
requirements  and  even  help  acquisition 
communities  select  the  proper  systems  to 
meet  those  requirements. 

Software  Development  Models 

As  presented  in  the  previous  section,  there 
are  many  compelling  reasons  for  the 
integration  of  M&S  with  C4ISR  systems. 
However,  if  the  reasons  for  integration  are 
so  good,  then  why  are  the  associated 
development  challenges  the  stuff  of  so  many 
program  managers’  nightmares?  A  primary 
factor  is  the  manner  in  which  most  M&S 
interfaces  are  developed  -  separately  from 
the  C4ISR  systems  that  they  will  eventually 
support. 

Separate  development  tracks  may  have 
occurred  due  to  the  fact  that  the  requirement 
for  the  M&S  internee  was  not  recognized  at 
the  time  the  original  C4ISR  system 
requirements  were  defined.  A  lack  of 
program  funding  can  also  cause  interfaces 
between  systems  to  be  pushed  back  to 
follow-on  development  efforts.  Regardless 
of  the  reason,  the  fact  that  highly  related 
software  projects  were  proceeding 
separately  warranted  a  fresh  look  at  the 
development  methodologies  being  used  to 
look  for  pitfalls  to  avoid  and  opportunities  to 
capitalize  on. 

Early  software  development 
models 

Developed  in  the  late  1960’s  and  early 
1970’s  and  still  popular  in  the  early  1990’s, 
the  waterfall  development  model  (see  figure 
1 )  was  the  guiding  design  principle  for  many 
of  the  software  systems  that  are  fielded 
today  [1].  Growing  out  of  refinements  to  the 
stagewise  model,  which  stipulated  that 
software  be  developed  in  successive 
stages,  the  waterfall  model  recognized  the 
presence  of  feedback  loops  between  stages 
(feedback  was  limited  to  the  previous  stage 
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only)  and  included  initial  incorporation  of 
prototyping  [2], 


Analysis 


Design 


Code 


Test 


Figure  1:  The  Waterfeil  Model 

Although  it  made  improvements  to  the 
stagewise  model,  the  waterfall  model  had 
several  limitations  itself.  First,  it  required  a 
complete  set  of  requirements  at  the 
beginning  of  the  project  [3],  something  that 
is  very  difficult  to  do  if  the  user  is  not  really 
sure  what  it  is  he  wants  (but  he  will  know  it 
when  he  sees  it).  Additionally,  the  waterfall 
model  delayed  the  detection  of  errors  to  the 
end  of  the  development  process  [1]  where 
they  were  the  most  expensive  and  time 
consuming  to  fix  and  where  there  was  the 
greatest  pressure  to  field  something. 
Finally,  nothing  is  done  on  the  project  until 
it’s  all  done  [4].  As  development  schedules 
get  tight,  the  customer  typically  wants  to  see 
some  type  of  product.  With  the  waterfall 
model,  there  was  nothing  to  show  but  a 
stack  of  documents  and  some  code  until  the 
end  of  the  project.  These  weaknesses  led 
to  the  development  of  another  model  known 
as  the  spiral  model. 

Spiral  development  model 

The  spiral  development  model  (see  figure  2) 
has  as  its  underiying  concept  a  series  of 
spirals,  each  cycle  of  the  spiral  consisting  of 
the  same  series  of  steps  as  the  previous 
cycle,  each  in  itself  similar  to  a  miniature 
waterfall  model.  An  important  feature  of  this 
model  is  that  each  spirai  of  this  iterative 


process  concludes  with  a  review  to  ensure 
that  all  participants  are  committed  to  the 
current  approach  before  proceeding  on  [2]. 
This  model  of  development  combats  many 
of  the  problems  of  the  waterfall  model  by 
allowing  the  developer  to  simultaneously 
seek  to  understand  the  problem  while 
searching  for  the  best  process  [5].  Rather 
than  oniy  doing  each  of  the  deveiopment 
phases  once  (i.e.  analysis,  design,  coding, 
testing)  the  cycle  is  repeated  several  times, 
each  time  getting  a  little  closer  to  the  desired 
finished  product. 


Figure  2:  Spiral  [)evelopment  Model 

The  spiral  model,  with  its  use  of  iterative 
development  and  prototypes,  is  seen  as  well 
suited  to  risky  development  projects  and  as 
such,  is  a  popular  model  among  aerospace, 
defense,  and  engineering  specialists  [3]. 

Coordinated  Spiral  Development 
Process 

Although  the  spiral  development  process 
has  aided  in  developing  new  C4ISR  systems 
by  allowing  operators  the  opportunity  to  try 
the  system  early  in  the  development  process 
and  offer  feedback,  in  some  respects  is  has 
farther  hampered  the  development  of  M&S 
interfaces.  With  the  current  implementation 
of  the  spiral  development  model  for  C4ISR 
systems,  products  are  being  fielded  at  an 
ever-increasing  rate. 

With  the  increased  rate  of  fielding  of  C4ISR 
systems  the  M&S  community  received  a 
commensurate  amount  of  new  requirements 
for  interfaces.  Unfortunately,  due  to  the 
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reduced  development  lead  times,  the  M&S 
community  would  often  only  find  out  about 
changes  to  C4ISR  systems  after  they  were 
fielded.  The  M&S  development  community 
had  also  embraced  spiral  development  for 
faster  production  times;  however  with  the 
late  identification  of  requirements,  the 
supporting  M&S  was  always  playing  catch¬ 
up,  as  illustrated  in  figure  3. 


Figure  3:  Current  Offset  Spiral 
Development 

The  offset  spiral  development  cycles 
between  C4ISR  and  M&S  caused  several 
problems.  First,  training  was  late  to  the 
field.  One  of  the  primary  roles  M&S 
interfaces  play  is  in  stimulating  real-world 


systems  for  the  benefit  of  training  system 
operators.  Since  M&S,  which  was 
compatible  with  the  new  C4ISR  systems 
didn’t  exist,  work-arounds  had  to  be 
developed.  Additionally,  the  added  benefits 
of  having  compatible  M&S  available  to  the 
C4ISR  developers  for  debugging,  as  well  as 
test  and  evaluation  purposes,  was  lost. 

Boehm  suggested  [2]  that  the  spiral 
development  effort  for  a  product  could  be 
split  amongst  multiple  organizations,  with 
each  organization  developing  a  portion  of 
the  whole.  This  split  development 
environment  was  very  similar  to  what  was 
happening  to  the  development  of  C4ISR  and 
M&S  systems.  Both  the  C4ISR  and  M&S 
developers  could  be  looked  at  as  jointly 
developing  a  larger  system  -  unfortunately 
via  disjointed  spirals,  the  goal  then,  was  to 
synchronize,  or  coordinate  the  development 
process. 

If  one  imagines  backing  up  the  M&S  spiral 
so  that  both  the  C4ISR  and  M&S  system 
were  starting  at  the  same  or  nearly  the  same 
time  (see  figure  4),  the  spirals  could  be 
linked.  Each  organization  maintains  a 
separate  development  effort,  but  comes 
together  at  key  reviews  for  course 
corrections.  This  method  has  the  added 
benefit  of  providing  the  C4ISR  developers  a 
stimulator  to  test  out  their  system  under  real- 
world  loads.  It  additionally  provides  the 
M&S  developers  some  level  of  confidence 
that  their  system  will  properly  interface  to  the 
real-world  C4ISR  system  once  fielded. 


C4ISR  System 

M&S  System 

Development 

DevelopmeDt 

Figure  4:  Coordinated  Spiral  Development 
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Coordinated  spiral  development  promises  to 
offer  many  benefits  to  the  combined  C4iSR 
and  M&S  system  developnient  effort. 
Factors,  which  Influence  system 
development  (seen  on  the  extreme  right  and 
left  sides  of  figure  4),  often,  result  in 
modifications  to  the  product  under 
development.  Under  spiral  development, 
these  changes  can  occur  quite  often.  Under 
the  coordinated  method,  these  changes  are 
now  communicated  much  earlier  to  the 
interfaced  system  resulting  in  fewer  fielding 
problems. 

The  Air  Force’s  newly  implemented 
experiment  series,  the  Joint  Expeditionary 
Force  Experiment  (JEFX),  provided  us  the 
perfect  opportunity  to  implement  the 
coordinated  spiral  development  process. 
The  Air  Warfare  Simulation  (AWISM)  had  a 
new  requirement  to  interface  to  the  Theater 
Battle  Management  Core  System  (TBMCS) 
which  was  one  of  the  primary  systems 
participating  in  JEFX.  Linking  the 
development  of  these  two  systems  would 
provide  us  valuable  insight  into  the 
coordinated  spiral  development  process. 

To  understand  the  challenges  faced  by  the 
developers  of  the  AWSIM/TBMCS  Interface 
(ATI),  it  is  helpful  to  have  a  basic 
background  of  the  interconnected  M&S 
(AWSIM)  and  C4ISR  (TBMCS)  systems. 
The  next  section  will  provide  that 
background  followed  by  an  explanation  of 
the  JEFX  program.  Finally,  this  paper  will 
present  some  of  the  lessons  learnt  from 
JEFX. 

System  Descriptions 

The  following  sections  provide  a  short 
description  of  each  of  the  M&S  and  C4ISR 
systems  used  as  successful  examples 
within  this  paper  of  the  coordinated  spiral 
process. 

Air  Warfare  Simulation 

AWSIM  is  the  United  States  Air  Force’s 
official  air  combat  simulation  model  [6]. 
AWSIM  is  used  to  train  senior  commanders 
and  their  battle  staffe  in  the  execution  of  joint 
and  combined  operations.  AWSIM’s 
computer  simulation  supports  air  component 


commander-level  battle  staff  training  for  Air 
Force  conducted  exercises  and  the  air 
portion  of  joint  exercises. 

AWSIM  is  a  real-time  interactive  simulation 
that  supports  a  two-sided  scenario.  Friendly 
and  opposing  sides  define,  structure,  and 
control  their  forces.  Neutral  air  forces  can 
also  be  portrayed.  Mission  packages  can 
be  developed  consisting  of  single  aircraft  or 
multiple-aircraft  missions.  Tail  number 
tracks  the  aircraft.  This  level  of  fidelity 
supports  training  requirements  of  the  Joint 
Forces  Air  Component  Commander 
(JFACC),  his  staff,  and  the  Air  Operations 
Center  (AOC)  that  develop  Air  Tasking 
Orders  (ATOs),  Rules  of  Engagements 
(ROEs),  and  target  nomination  lists. 

AWSIM  is  a  latitude  and  longitude  based 
theater-level  model.  It  simulates  day  and 
night  operations.  Modeled  features  include; 
aircraft,  air  bases,  surface-to-air  missiles 
(SAMs),  Short  Range  Air  Defense  Systems 
(SHORAD)  radar  sites,  surface-to-surface 
missile  (SSM)  sites,  and  cruise  missiles. 
AWSIM  also  contains  All  Range  Air  Defense 
Systems  (ALLRAD)  or  those  systems  whose 
fire  control  can  be  transferred  between 
AWSIM  and  the  Army’s  Core  Battle 
Simulation  (CBS)  model. 

AWSIM’s  scope  is  limited  to  conventional 
warfere,  but  can  conduct  nearly  all  Air  Force 
defined  missions  and  includes  virtually  all- 
conventional  air-to-air,  air-to-surface,  and 
surface-to-air  weapons.  AWSIM  missions 
consume  munitions  and  fuel  on  an  “as  used” 
basis.  AWSIM  uses  Monte  Carlo  for 
probability  of  kill  attrition.  AWSIM  supported 
missions  and  functionality’s  are  listed  in 
Table  1. 


Air-to-Air 

Reconnaissance 

Airborne  Early  Warn 

Aerial  Refueling 

Air  Interdiction 

Helicopters 

Battlefield  Air  Ind 

Cruise  Missile 

Close  Air  Support 

Surface-to- 

Sur^ce 

Electronic  Combat/ 
Electronic  Warfare 

Surface-to-Air 

Airlift 

Weather 

Table  1:  AWSIM  Mission/Functionality 
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AWSIM  graphics  display  or  Graphic 
Interface  Aggregate  Control  (GIAC)  contains 
menu  options  for  controlling  aircraft,  air 
defenses  as  well  as  filters  for  information 
viewed,  map  scales,  and  the  ability  to  add 
text  and  lines  (such  as  the  Forward  Line  of 
Own  Troops  (PLOT)  or  transit  routes). 

AWSIM  has  Air  Status  Boards  (ASTABs)  to 
portray  information.  These  boards  contain 
data  on  air  base  status,  logistics,  history  of 
missions,  history  of  destroyed  aircraft,  radar, 
and  active  flights.  ASTABs  also  have 
filtering  ability. 

AWSIM  database  requirements  for  an 
exercise  are  the  unique  force  structure  and 
targets.  This  includes  items  such  as  air 
bases,  assigned  squadron  names,  squadron 
aircraft  type  and  number,  early  warning 
radars,  and  air  defense  sites. 

Theater  Battle  Management  Core 
System 

TBMCS  consolidates  force-level  and  wing- 
level  command  and  control  systems  that 
utilize  the  Air  Force  Theater  Battle 
Management  (TBM)  Command,  Control, 
Communications,  Computers,  and 
Intelligence  (C4I)  standards  n.  The 
acquisition  of  this  system  allows  the 
execution  of  TBM  planning,  intelligence,  and 
operational  functions  in  support  of  the 
JFACC.  The  system  provides  connectivity 
horizontally  to  other  Services  and  allies  and 
vertically  among  standard  or  composite 
wings,  other  elements  of  the  theater  control 
system,  and  deployed  units  and  higher 
headquarters.  It  is  modular  to  build  up  or 
scale  down  capabilities  by  adding  or  deleting 
information  sources,  operating  units, 
weapons  available,  participating  Services 
and  allies,  and  dispersal  requirements.  Data 
and  functions  are  distributed  for  survivability. 
Department  of  Defense  (DoD)  and  TBM 
General  Officer  Steering  Group  (GOSG) 
open  system  standards  applies  to  the 
system.  TBMCS  provides  automated 
decision  support  tools  to  improve  the 
planning,  preparation,  and  execution  of  joint 
air  combat  capabilities.  It  also  provides 
support  for  peacetime  operations,  e.g., 
humanitarian.  United  Nations  peacekeeping, 
etc.  Advanced  technology  is  transitioned  to 


the  field  using  evolutionary  acquisition  and 
rapid  prototyping.  To  meet  operational 
performance  criteria,  TBMCS  receives, 
displays,  and  integrates  into  related 
applications  of  current  space,  air,  ground, 
and  maritime  situations  as  provided  by  US 
and  allied  sensors  and  specified  ground 
processing  elements.  AF  Space  Command 
(AFSPC)  provides  the  theater  with  space 
support  (i.e.,  satellite  imagery,  satellite 
weather  data.  Global  Positioning  System 
(GPS)  data,  launch  information,  etc.)  for 
battle  management. 

Two  core  components  of  TBMCS  that 
directly  interact  with  AWSIM  are  the  combat 
planning  and  combat  operations  modules. 

The  combat  planning  module  provides 
automated  decision  support  to  combat 
planners  for  preparing  the  ATO.  It  keeps 
track  of  resource  status  and  can  provide 
proposed  mission  packages,  routing,  tanker, 
and  Electronic  Counter-  Countermeasures 
(ECCM)  support,  etc.  for  planners’  approval. 
It  is  required  to  reduce  ATO  cycle  time. 
Additional  automation  will  support  planning 
for  electronic  warfare,  airspace  control, 
communications/ffequency  management, 
reconnaissance  tasking,  and  ancillary 
support  as  required. 

The  combat  operations  module  provides 
additional  automation  to  the  combat 
operation  division  for  the  command  and 
controi  systems  architecture  for  the  Combat 
AF  (CAF)  to  assist  in  the  near  real-time 
monitoring  and  execution  and  replanning  of 
the  ATO  based  on  rapidly  changing 
battlefield  conditions.  It  also  provides  for 
automated  assistance  to  the  JFACC  and 
staff  to  monitor  force  structure  status  and 
composite  displays  of  the  battlefield  in  near 
real-time. 

AWSIM  -  TBMCS  Interface 

The  AWSIM-TBMCS  Interface  (ATI)  is  a 
program  designed  to  interface  the  real-world 
TBMCS  system  with  the  AWSiM  wargaming 
system.  ATI  allows  the  database  that  the 
Combat  Panning  module  of  TBMCS  utilizes 
to  be  mapped  to  an  existing  AWSIM 
database.  ATI  provides  automated  support 
for  loading  a  TBMCS-generated  ATO  into 
AWSIM,  producing  AWSIM  mission  order 
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stacks,  and  a  mission  editing  capability. 
Personnel  in  an  air  component  response  cell 
use  the  ATI  to  create  files  that  define  a 
specific  mission  such  as  close  air  support 
including  aircraft  type  and  number,  weapons 
load,  take-off  time,  transit  routes,  refueling, 
target,  and  the  way  home.  The  missions  are 
launched  at  the  appropriate  times  and  flight 
followed  by  the  response  cell  which  can 
adjust  the  flight  profile,  if  required.  Results 
of  the  mission  including  kills,  losses,  and 
success  are  displayed.  ATI  also  supports 
the  communications  of  mission  takeoff  and 
landing  times  from  AWSIM  to  TBMCS. 

Joint  Expeditionary  Force 
Experiment  Program 

JEFX  provides  the  Air  Force  with  a 
semiannual  vehicle  for  experimentation  with 
operational  concepts  and  attendant 
technologies  for  enhancing  capabilities  of 
the  21st  century  Aerospace  force  [8].  The 
experimentation  will  lead  to  new  ways  of 
accomplishing  Air  Force  missions,  while 
motivating  leading-edge  thought  and 
encouraging  operational  activities  that  will 
significantly  advance  Air  Force  Core 
Competencies  as  the  Air  Force  prepares  to 
fight  the  nation's  conflicts.  The  JEFX 
program  provides  mechanisms  for 
transitioning  proven  initiatives,  to  serve  as 
operational  leave-behinds  or  as  candidates 
for  incorporation  into  the  formal  acquisition 
cycle. 

JEFX  concent 

The  overall  JEFX  concept  calls  for  the 
deployment  and  employment  of  an  Air 
Expeditionary  Force  (AEF)  into  a  large 
asymnietric  force-on-force  simulated  combat 
scenario  [9].  The  Experiment  Director  will 
incorporate  live-fly  activities  of  a  Rapid 
Response  Air  Expeditionary  Force  (RAEF), 
along  with  virtual  and  constructive 
simulations  as  an  operational  laboratory. 
The  design  supports  experimentation  with 
concepts  and  systems  intended  to  improve 
Air  Force  capabilities  in  three  C2  focus 
areas;  Global  Awareness  (GA),  Global  Grid 
(GG);  and  dynamic  Analysis,  Planning,  and 
Execution  (dAPE).  These  three  C2  focus 
areas  are  outcomes  of  the  Air  Force  C2 
Summit  in  June  1997  [10].  It  is  envisioned 


that  enhancements  in  these  C2  capabilities 
will  improve  Air  Force  operational 
capabilities  and  Core  Competencies. 

JEFX  will  experiment  with  advanced  C2 
technologies  to  enable  use  of  fixed  and 
deployable  C2  centers  along  with  distributed 
and  collaborative  planning  tools.  It  will 
integrate  information  technologies  with 
robust  communications  and  exploit  new  C2 
concepts,  processes,  and  procedures.  JEFX 
will  establish  and  leverage  the  capabilities  of 
GG,  GA,  and  dAPE.  In  a  limited  warning  (48 
hours)  scenario,  JEFX  will  demonstrate  the 
unique  qualities  of  Aerospace  power  (speed 
range,  flexibility,  lethality)  and  apply 
adequate  lethal  force  within  the  early  halt 
phase  (first  15  days)  to  forge  a  decisive 
edge  [1 1]. 

JEFX  mission 

The  JEFX  mission  is  to  conduct  a 
semiannual  CSAF-sponsored,  MAJCOM- 
executed  experiment  that  combines  live-fly 
forces,  constructive  and  virtual  simulations, 
and  technology  insertion  into  a  seamless 
warfighting  environment.  The  purpose  of  this 
experimentation  is  to  demonstrate 
dramatically  enhanced  C2  capabilities  and 
weapons  in  the  application  of  integrated 
Aerospace  power  to  advance  Air  Force  Core 
Competencies. 

JEFX  goals 

Numerous  benefits  are  expected  from 
serniannual  JEFX  experimentation.  JEFX 
initiatives  and  technologies  should  reduce 
overall  manpower  requirements,  particularly 
the  footprint  of  forward  deployed  forces.  It 
will  be  able  to  leverage/emphasize 
Aerospace  power’s  speed,  global  range, 
flexibility,  and  lethality.  JEFX  will  allow  us  to 
"train  the  way  we  fight,"  within  the  context  of 
a  standing  Joint  AOC  (JAOC).  Using 
lessons  learned,  the  Air  Force  can  guide  the 
planning  and  execution  of  the  annual 
warfighting  experiments  focusing  on 
accelerated  development/fielding  by 
implementing  initiatives  through  the  spiral 
development  process.  This  innovative 
process  co-evolves  concept,  process,  and 
people  and  ultimately  improves  acquisition 
responsiveness. 


7 


JEFX  objectives 

JEFX  objectives  guide  the  general 
arrangement  of  experiment  activities,  the 
establishment  of  criteria  for  acceptance  of 
conceptual  and  technology  initiatives  for 
experimentation  and  the  definition  of 
planning  limits  for  experimentation.  JEFX 
will  institute  and  continuously  employ  a 
spiral  technology  development  process  to 
expeditiously  introduce  new  technologies 
and  operational  concepts  spanning 
development,  experimentation,  and 
int^ration  of  enhanced  capabilities  into  the 
active  inventory.  JEFX  will  explore  AEF 
capabilities,  baseline  C2  capabilities  and 
provide  insights  for  C2  Roadmap  plans,  and 
evaluate  and  recommend  changes  to 
current  doctrinal  procedures  for  contingency 
response  operations  and  Core 
Competencies.  Finally,  it  will  establish  the 
JEFX  process  as  the  mechanism  to 
introduce  and  evaluate  technologies  and 
operational  concepts  for  enhanced 
applications  of  Aerospace  power. 

JEFX  Utilization  of  the  Spiral 
Development  Process 

The  nature  of  spiral  development  and  how  it 
supports  innovation  critical  to  the  Air  Force’s 
developmental  community  define  the  JEFX 
process.  The  spiral  development  process 
takes  emerging  and  maturing  technologies 
and  transforms  them  into  fielded  systems  or 
concepts  through  a  chain  of  analysis, 
prototyping,  battlelab  development, 
experimentation,  and  operational 
evaluations.  JEFX  is  a  key  aspect  of  the 
experimentation  process,  as  each  JEFX  will 
incorporate  selected  battlelab  development 
efforts,  with  conceptual  and  systems 
initiatives  offered  up  by  government 
sponsors  and  industry,  to  advance  Air  Force 
Core  Competencies. 

Lessons  Learned 

JEFX  provided  an  excellent  opportunity  to 
explore  the  capabilities  of  the  coordinated 
spiral  development  model.  The  opportunity 
to  have  the  M&S  interface  available  for  initial 
spiral  events  allowed  ATI  and  TBMCS  to 
mature  jointly,  aided  in  test  &  evaluation  and 
helped  to  provide  for  training  initial  cadre. 


The  Air  Force  Agency  for  Modeling  and 
Simulation  after  action  report  [12]  on  JEFX 
highlighted  this  fact.  “The  simulation 
environment  allowed  Air  Force  personnel  to 
examine  and  refine  their  functional 
processes  on  how  they  would  use  TBMCS 
to  execute  air  warfare.  Flexibility  of  the 
simulation  systems  to  rapidly  configure  and 
stimulate  different  C4ISR  configurations  with 
different  interfaces  provided  a  cost  effective 
testbed  environment.”  The  C2  Earlybird; 
JEFX  lessons  learned  edition  [13],  also 
noted  “The  linking  of  C4ISR  and  M&S  spiral 
development  was  very  successful.  The 
development  of  the  AWSIM/TBMCS 
Interface  concurrently  with  TBMCS  provided 
the  TBMCS  developers  a  tool  to  use  for 
system  tests  and  gave  the  M&S  world  the 
capability  to  interface  with  this  new  C4ISR 
system  as  soon  as  it  was  released  to  the 
players.  We  must  continue  to  link  C4ISR 
and  M&S  development.” 

One  of  the  keys  to  the  success  of  the 
implementation  of  the  coordinated  spiral  at 
JEFX,  was  the  excellent  working  relationship 
that  existed  between  the  developers. 
Although  this  developed  at  the  grass  roots 
level  out  of  necessity,  in  the  future  this 
relationship  must  be  formalized. 
Development  work  beyond  the  JEFX 
environment  was  hampered  by  the  lack  of  a 
formalized  Interface  Control  Document, 
which  would  have  helped  JEFX  as  well. 

Even  with  the  shortened  development  times 
and  the  benefits  associated  with  having  an 
M&S  interface  available  immediately  upon 
C4ISR  system  fielding,  there  are  still 
questions  as  to  if  this  manner  of 
development  lowers  costs.  The  concern 
here  is  that  even  with  the  M&S  and  C4ISR 
systems  being  developed  separately  there 
are  still  costs  associated  in  the  C4ISR 
system  development  that  did  not  exist  prior 
to  working  with  the  M&S  systems.  If  one 
considers  operational  readiness  of  the 
C4ISR  system  to  be  the  desired  endstate 
then  the  cost  of  operational  readiness  would 
be  the  cost  of  all  the  preceding  events 
leading  up  to  that  endstate.  This  includes 
not  only  the  funds  spent  for  acquisition  but 
for  the  test  &  evaluation  and  training  to 
reach  that  goal.  At  the  time  of  JEFX,  I  was 
unable  to  gather  cost  information  for 
previous  interface  developments  to  compare 
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against  the  coordinated  spiral  effort.  The 
telief  is  that  the  development  time  saved 
due  to  a  higher  quality  test  &  evaluation 
phase  and  increased  training  quality  (i.e. 
fewer  training  days)  outweighs  interface 
development  costs  as  compared  to  those 
systems  developed  in  the  non-coordinated 
manner  using  waterfall  or  follow  -  on  spiral 
efforts. 

Summary 

The  coordinated  spiral  development  process 
as  applied  during  JEFX  matured  the  ATI 
project  along  with  AWSIM  and  TBMCS 
systems,  providing  a  working  C4ISR  and 
M&S  interface  much  earlier  than  had  been 
^en  during  previous  interface 

developments.  Additionally,  the  availability 
of  a  M&S  interface  for  testing  TBMCS  aided 
developers  greatly  as  witnessed  by  their 
requests  to  leave  the  simulation 

environment  active  after  training  was  done 
for  the  day  for  test  purposes.  Future  efforts 
wich  compare  the  fielding  costs  of  systems 
built  under  the  coordinated  spiral 
development  environment  with  the  costs  of 
those  systems  developed  under  the  waterfall 
or  follow  -  on  spiral  efforts  should  show  a 
cost  savings  and  quality  improvement  for 
systems  built  in  the  coordinated 
environment. 
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